GreenSock

It's beyond the scope of help we can provide for free in these forums, but perhaps this will help get you going in the right direction: https://codepen.io/GreenSock/pen/yLWOGxo?editors=1010

Oh, it looks like a logic problem in your code - you're recreating the animations EVERY time animationClients() is called. And you're creating them AFTER you run your pause/play logic. I assume you meant to create the animations once (outside that function), and then just play/pause them as necessary, rather than creating them over and over again inside that toggling function. If you still need help, please make sure you only include a minimal demo - your demo had 400+ lines of code. That makes it very cumbersome to troubleshoot and it's beyond the scope of help we can provide here. Just recreate the problem in the simplest form possible. No need to include your real project. Just some simple colored <div> elements is fine.

There's no such thing as "stop()" on a tween/timeline. Did you mean pause()? It seems like a strange way to engineer things - if you want it to repeat an animation twice, why not just wrap it in a timeline that has repeat: 1? And why are you embedding part of the animation that you don't want to repeat into the timeline? Why not either treat that as an independent animation, and fire off the repeating one in an onComplete? Or sequence them in a master timeline? Sorta like: let intro = gsap.timeline(); intro.to(...); let repeatedTL = gsap.timeline({ repeat: 1 }); // play twice repeatedTL.to(...).to(...).to(...); let master = gsap.timeline(); master.add(intro) .add(repeatedTL);

You're completely deranged. 🤣 Kidding. killing an animation just stops its changes immediately - it doesn't revert the state back to what it was before the animation started. That's what revert() is for. I'd strongly recommend watching this video if you haven't already: I'm not sure what you mean. What "object values"? When an animation renders for the first time, it records the start/end values internally so that it can very quickly interpolate between them. You can flush those values by calling invalidate() on an animation/timeline and then the next time it renders, it'll record them at that point again. It sounds like your minimal demo doesn't actually show the heart of what you're trying to do (multiple states?) - if you still need help, I'd encourage you to provide a minimal demo that very clearly shows the problem you're trying to solve (in as minimal a way as you can). We're not React experts, but I can tell you for sure that the way React does things makes it a little tricky to get used to. GSAP works exactly the same no matter where you use it, and it's totally compatible with React. It's just that as a developer, you need to kinda understand what React does to avoid some of the gotchas (unrelated to GSAP).

No no, you don't need to kill the other timelines if you don't want to. The core problem is just a logic one in your code - you're animating to an absolute rotation value of 360 on click, over the course of 3 seconds. Obviously the rotation starts at 0, so the first time you click it'll start animating to 360 over the course of 3 seconds, which means 120 degrees per second (speed). But then let's say you click again when the rotation is at 180 degrees (halfway). Well now you're setting up a timeline to go from whatever it currently is (180 degrees) to 360 degrees over the course of 3 seconds! So now it only has to travel half that distance (180 -> 360) but using the same duration, thus it's traveling at half the speed (60 degrees per second). There are quite a few things that seem awkward in your demo code. Why not just create 1 animation for each, and pause() them initially. Then, resume()/pause() them on click? Your click event handlers are unconventional for React too. And if you're going to handle them that way where you're creating new animations inside the click event handler, you should use the contextSafe() method to ensure that they're properly added into the useGSAP() context and get cleaned up properly in React. And if you're doing the same kind of animation for all the elements, you could probably use Arrays and loops so that you're not repeating so much in your code. Thanks for being a Club GSAP member! 💚

Glad you figured it out. By the way, I did create a little helper function that might be useful here: Enjoy!

I don't have much time right now, but I very quickly made an edit: https://codepen.io/GreenSock/pen/gOJPZqM?editors=0010 You were just killing the scrollTween and creating a whole new one, but you forgot to reset the position. So, for example, if you resized the window after the scrollbar was already 500px down from the top, you'd be creating the new scrollTween from that [new] position instead of from 0.

Hm, I'm not quite sure what you mean. I'm not seeing any jump at all. Please also keep in mind that SplitType is not a GreenSock product, so we can't really support that here. Is there some secret to seeing this "jump" that you're describing?

Sorry about the delay and the confusion, @Grene Thanks for pointing this out - there was indeed a bug that could affect orientation changes (they wouldn't fire a ScrollTrigger.refresh() properly. That should be fixed in the next release which you can preview at: https://assets.codepen.io/16327/ScrollTrigger.min.js In the meantime, there's an easy workaround: let mm = gsap.matchMedia(); mm.add("(orientation: portrait)", () => { ScrollTrigger.refresh(); return () => ScrollTrigger.refresh(); }); Technically, you could do this instead, but I don't think it's as well-supported across browsers: window.addEventListener("orientationchange", () => ScrollTrigger.refresh()); Does that resolve things for you?

From the docs: There is a helper function that can help in that situation. You also need to make sure the elements are in the document flow so that calculations can be done correctly, but you had display: none on the parent. So you could toggle that for the split. https://codepen.io/GreenSock/pen/RwmrWPy?editors=1010 Better?

This thread may be helpful: Good luck!

Anytime! 🙌

Pseudo elements are not accessible to JavaScript. That's a browser limitation, unrelated to GSAP. Usually a good workaround is to use CSS variables (GSAP can animate those), but that might be tricky for a drawSVG effect. If you can use a normal element, that's probably best.

One other guess: make sure you register the useGSAP hook and ScrollTrigger: gsap.registerPlugin(useGSAP, ScrollTrigger);

Hi @pedrobear. There's a lot of very custom logic in that CodePen demo, and it's well beyond the scope of help we can provide for free in these forums, but if you'd like to isolate a very specific problem in a much simpler version, we'd be happy to take a peek and help with any GSAP-specific questions. It looks likely to me that the snap-back with the arrow functionality has to do with logic flaws in where you're animating to (calculations). As for being sluggish, there are a lot of factors with that (performance is a very deep topic), but one possibility is that browsers have rendering engines that are optimized for vertical scrolling, not as much horizontal scrolling, so you may be hitting some browser-specific optimization limitations. For example, I know that if you have elements that go beyond a certain width, the browser forces it to get broken into multiple tiles for the graphics renderer, and switching between them can be a little expensive. None of that has anything to do with GSAP. Good luck!